-
Notifications
You must be signed in to change notification settings - Fork 2
feat: binary trace format #19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This is preparation for creating a workspace, which will contain the library and a command line tool.
This is just a copy of the bulk conversion code from my command line json<->bin conversion tool. These are not fully integrated into the runtime_tracing library, yet.
…e of conversion between binary and json trace formats
…ite() is not guaranteed to write the entire buffer
runtime_tracing/src/capnptrace.rs
Outdated
| use crate::{TraceLowLevelEvent, VariableId}; | ||
|
|
||
| fn conv_typekind(kind: crate::TypeKind) -> trace::TypeKind { | ||
| match kind { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe create a macro for these pattern matches ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO, it's not worth the effort. Long term, I'm planning to reimplement this in a different language, where we can also easily read and write this as a memory mapped file. Doing this in Rust would be such a pain in the ass, it's not worth the wasted development time. Well, unless you never want to see this feature finished, then we can stay with Rust and get swamped into debugging some shitty macros instead of doing anything actually useful :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another reason not to use macros: the structs generated from the capnp file are different from the Rust structs; any disagreement between these will lead to nasty, difficult to debug macro errors
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By different, I mean that, in principle, we want to be able to evolve the .capnp format separately from the json format (which is tied to the Rust structures and enums, due to the way serde macros work). That being said, at a certain point, we probably want to drop the json support entirely, but who knows when that will happen - we need to implement binary writing support in our supported debuggee languages - Noir, Ruby, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. Sounds good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can just implement From and Into traits for our 2 TypeKind types ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initial implementation of a binary trace format, based on capnproto. Also adds a tool 'runtime_tracing_cli', capable of conversion between the json and the binary formats.
For lack of a better idea, I used the '.bin' file extension for the binary format, i.e. 'trace.bin'. Better ideas for an extension are welcome!
Noir support is being worked on in this branch:
https://github.com/blocksense-network/noir/tree/nargo_trace_plus_binary
(expect regular rebasing and force pushing, until this is merged into the nargo_trace branch, which is still awaiting review from the upstream Noir developers).
CodeTracer support in the db-backend should be easy to add also, once this is merged.